My previous entry about a fellow developer's GPG key causing nasty spew from gpg on my system provoked an unhappy response. I had hoped to instead stimulate a discussion^* of the problem — whether a bug in GPG, a bug in the key servers, or both. From Alexander's explanation, it looks like it's the latter. If a hunk of your key gets corrupted and then submitted to the public key servers, ever, then there's apparently no in-band way of signaling that to those key servers. Apparently you have to contact the humans who administrate the key server and arrange for something approaching divine intervention (in the sense that any large database that has many simultaneous reads and writes going on at all times via defined interfaces really should not have people mucking around with its innards in an ad hoc fashion). Just off the top of my head, it seems like one should be able to submit a GPG-signed copy of one's own entire keyring to the key servers, and have any key signatures within that be regarded as "authoritative", only capable of supersession by another signature bundled in a keyring signed by the keyring's owner. The handling of signatures not in that signed keyring would not change. (It does occur to me, though, that this means that the key servers are susceptible to an annoying attack wherein people can deliberately add corrupt signatures to other people's keys and promptly upload those keys to the public key servers. It would also be easy to automate such an attack. Oy vey. Consequently, it might be worth considering a key-owner-only update model for keyrings on the key servers.) Debian relies heavily on its web of trust, and on the GPG application specifically, and it seems a shame that this problem hasn't been addressed by now. Do we need a new protocol for communicating with key servers? Is my suggestion above completely crack-addled? If you didn't get the chance to flame me for my previous entry, don't miss your opportunity this time around. ;-) Another possibility would be to change GPG so it doesn't complain about the sorts of problems it found in my message, but that seems suboptimal. Well, okay — I'll say it — grody. Errors in any large collection of data, such as the keyrings in the OpenPGP global web of trust, are inevitable. Corrupt data is corrupt data, should be reported as such, should be susceptible to rectification, and that rectification should be able to be propagated. It seems the PGP key servers — the ones I and many other Debian developers use, anyway — are not entirely succeeding on the last front. What can we Debian geeks, as prominent contributors to the global web of trust, do to resolve the problem? Alexander: I'm sorry I gave offense, if inadvertently and only temporarily. There are certainly no hard feelings on my part. I don't really know how to constructively reply to Matthew, given his patient explanation to me at DebConf 5 that the entire purpose of that specific blog of his is to serve as a vent for his spleen — he has another for the serious stuff. Since it seems to be necessary to state this for the record, I don't regard damaged packets in a person's GPG keyring to be evidence of flaws in the owner's character or personality, or as anything to be ashamed of, but I must admit that I didn't consider that others might do so. I see a technical challenge to be surmounted (noisy spew from the gpg program that seemingly can't be eliminated without improving the way GPG clients and key servers communicate), and that's about it. I welcome people's ideas on resolving it — is there a Public Key Server Corrigendum Protocol in our future, perhaps? ^*Being relatively new to blogging, it's certainly possible I have in mind a meaning of "discussion" in mind that is excessively mundane, and not the norm. I can easily conceive that people who use their blogs primarily as megaphones to air their grievances (and there are many — one of my favorites is Billmon) are more likely to assume others apply their blogs to the same end. I'll need to give that conception more weight in the future.

$ gpg --list-key 8DF5C27F
gpg: buffer shorter than subpacket
gpg: signature packet without timestamp
gpg: buffer shorter than subpacket
gpg: signature packet without keyid
gpg: buffer shorter than subpacket
gpg: buffer shorter than subpacket
gpg: signature packet without timestamp
gpg: buffer shorter than subpacket
gpg: signature packet without keyid
gpg: buffer shorter than subpacket
pub   1024D/CD15A883 2002-09-28
uid                  Alexander Schmehl (privat) <alexander@schmehl.info>
uid                  Alexander Schmehl (private) <tolimar@schmehl.info>
uid                  Alexander Schmehl (knOEpix) <alexander@knoepix.org>
uid                  Alexander Schmehl (Skolelinux) <alexander@skolelinux.de>
uid                  Alexander Schmehl (university) <schmehl@cs.uni-frankfurt.de>
uid                  Alexander Schmehl (university) <schmehl@informatik.uni-frankfurt.de>
uid                  Alexander Schmehl (unused, but read) <alexander.schmehl@schlundmail.de>
sub   2048g/8DF5C27F 2002-09-28

Alexander, please repair your GPG key and upload a new version to the keyservers. The above spew every time I do ordinary gpg operations (like --check-trustdb) drives me up the wall, and I suspect I'm not the only one. John Goerzen used to have damage to his key — I think it was caused by a bug in a pre-1.0 version of GNU Privacy Guard (GPG). Maybe he has some tips for fixing the key. If it's only the ElGamal subkey that's damaged — which is how it looks to me — then it should be possible to replace it. It might just be that the public keyservers (like subkeys.pgp.net, which I use) have a corrupted copy of your key. You might try re-submitting it, like this:

gpg --keyserver subkeys.pgp.net --send-keys CD15A883

Interestingly, of all the key exchanges I've done over the past 6 years or so, I can only think of these two instances of key corruption. I suspect that says a lot for the robustness of GPG. This message was brought to you by the Pedantically Correct Public Key Cryptography Association. No Alexander Schmehls were harmed in the creation of this message (I hope ;-).)

Last night at the "formal dinner"^* at DebConf 5, Anand Kumria presented me with a nice little tote bag that says "Debian: 10 years, 100 countries, 1000 developers, 10000 packages". It's a couple of years out of date now, but still pretty cool. Anand suggested that we give it away as a sort of prize. Since I was sitting across the table from former DPL Wichert Akkerman and we had two other former DPLs in attendance, Bdale Garbee and Ian Jackson, I thought I'd sweeten the item's collectibility by having all of us autograph it. This was swiftly done. After much dithering among my tablemates and I, and many ideas that fizzled regarding closed bugs or frequency of usage of the term "cabal" on the mailing lists, we ultimately settled on a method that was reasonably fair, if boring: the old game of "guess the unsigned 16-bit integer". We went outside and proceeded by binary search, disqualifying half the group at a time. The ultimate winner was Frank Lichtenheld, who guessed that the number was between 20k and 24k. ^*Fortunately, the dress code was not formal — the formality was that we ate from plates instead of cafeteria trays. ;-).

I have issued my first report as Debian Project Leader.

Anthony Towns will be Debian’s next project leader. I am not happy with that outcome at all. With just a tiny margin, aj has won over Steve. Steve was not my favorite candidate as well, but he’d be better than aj, who in my opinion stands for the cabal that is running Debian from their positions of power for years now. Only 421 DDs have cast their vote, which is 43.3128% of all possible votes. Voter participation has thus been lower than the historic low Germany’s state Sachsen-Anhalt recently had in its Landtag election. More than half of the DDs do not seem to be interested in who makes Debian’s external policy and who represents the project to the outside. On the other hand, debian-vote sees a number of people who are not currently allowed to vote, but regularly contribute to Debian. It looks like the people who could vote don’t, while people who do good things to Debian are not allowed to vote. Bad. But, IMNSHO, the really bad thing is the new DPL itself. I think he has won the election with saying that he will increase Debian’s speed. On the other hand, he is member of ftpmaster, the team that might be one of the biggest causes for Debian’s slow speed. He is generally regarded to be close to the “Cabal”, which of course does not exist. I don’t see how the speed increase is can be accomplished giving this background. However, the vote can easily be interpreted as a vote of confidence in the Cabal, which in itself is a good thing. It shows that even the voting DD’s are comfortable to be ruled by the secret club of most senior DDs. I don’t have to like it, but I’ll have to live with it. aj is also one of the founders of #debian-tech, an IRC channel which has been created as a “nice” channel for technical discussions. The channel has a very strict code of conduct, and people are being removed from the channel if they do not comply. I am really really really afraid of this “be nice or else” attitude being extended to other Debian communications media during aj’s term. Being robbed of the right to speak one’s mind might adversely affect many people’s motivation to spend time with Debian in the future. In a nutshell: This is a sad day for Debian. But, otoh, every project gets the leadership it deserves. And it looks like Debian didn’t deserve any of the better candidates. jftr, I voted 63571824 Be warned: I have a bad history of mis-judging new DPLs just after their election. A year ago, I was quite happy about Branden being elected, and was convinced that things would change during his first term of DPLship. I really believed that he could remove the Cabal from the power, and that Debian would change to a more co-operative environment. I surely hope that I am as wrong this time as I was a year ago. It’ll be more positive this time.

The Debian Project, in an inspired move to improve to reduce stress stemming from overwork, locked out its developers from debian.org machines. This experiment was a complete success. With no way to do uploads, or to read web logs on Planet Debian, Debian developers the world over had a very relaxing two days of vacation. "Morale is up 1.3%", boasts Debian Project Leader Branden "aj" Robinson, adding "it only took four hours to unstick my finger from the Planet reload button, so that I could get up and have a shower". Asked whether the project would recommend the same procedure for other free softare projects, Robinson replied, "You betcha". Open source mastodont Microsoft founder Bill Gates concurs. "We've been doing the same thing for years. We have an entire team devoted to keeping backdoors open for just this kind of opportunity." Independent IT expert Lars Wirzenius jumps on the bandwagon. "Yes! A very good idea! I'll happily sell my services to anyone who wants to add a backdoor to their system. I'll make two for the price of one!".

Now that the right people have been told, I can make it public: as of January, I’ll be a full-time developer for the Free Standards Group, producers of the LSB. This is, perhaps, one of the most difficult job decisions I’ve had to make. In every other case where I’ve changed jobs so far, I’ve done so only when it becomes clear that the old job isn’t going anywhere: either by going under, getting radically reorganized, treating me poorly, or otherwise being a dead end. None of that is true here. I still believe in what Progeny is doing. The co-workers are superb (yes, even that one), and management has always treated me well, even in difficult circumstances. But sometimes, opportunities are too good to pass up. I think that the next year or two will be pivotal to the future of free standards, and I’ll be in a unique position to influence the direction those standards go. Plus, I’ll be able to work with another group of brilliant and talented people, with the hope that some of that brilliance and talent will rub off. I’m also positive about working primarily from home. So, you can expect more blogging (he says, a month after his last post!), especially about standards in the free software world. I’ve created a new category for that topic, in case you’re interested in following just that conversation.

Via reddit (which kicks the crap out of slashdot and digg): What I've Learned From Failure.

The link above is a long, but fascinating piece. I've had to become a lot more interested in how to manage software projects since taking on Xorg maintainance, and the same lessons seem to scale up well to how Debian as a whole manages itself. This article talks about some of the major problems that I've seen myself deal with, and the experiences of this guy echo my own over the past year very strongly. Here's a few examples:

"Getting away from weak teams, another source of failure is the omnipresent threat of "chickens." A chicken is not necessarily a weak individual, but a sign of a weak management structure. A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project. Significant authority includes the authority to impose constraints on the team."

I like this and I've noticed it in the XSF and in Debian as a whole. People are free to work on what they want how they want, and this tends to work out well for us. But we also have no structure in which people must actually commit to what they do. As such, there's no accountability. This frees Debian developers from the preassure of having to work on something they don't enjoy, but it also creates abandoned packages, ignored bugs, and frustrated release schedules. In the past I've described a need for a stick in addition to a carrot for Debian developers, and the sentiment here echoes that idea. I've spoken with Manoj about his conception of personal responsibility in Debian, and I think it may truly be the bedrock on which Debian needs to rest. I still don't have a good mechanism for this yet though.

"Another sign of a weak team is poor development hygiene. There are dozens of development practices that seem trivial to the inexperienced outsider or to the manager focusing on "big wins." Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews)."

This is a something I myself have had a problem with over the past year. Branden was extremely good about keeping the XSF svn repo and the BTS up to date and well managed. I've done just about the opposite over the past year, and it's bitten me a few times. This however, was a conscious decision on my part, knowing that I was so far behind upstream that it was going to be hard to effectively manage the BTS without a recent codebase deployed to our users. So I focused on packaging instead, and luckily that road is nearly finished. Also fortunately, everyone else in the XSF managed the BTS for me, most notably (in alphabetical order by last name) Julien Cristau, Michel D nzer, Eugene Konev, and David Martinez Moreno, and they've managed to keep it relatively tidy. I'm going to spend some serious effort over the coming months to clean out the BTS so it's more manageable both for users and developers again. Luckly our SVN repo is in good shape still, so for the most part we're doing pretty well here. Debian as a whole also seems to be doing better at this, with lots of public svn repos springing up on alioth.

"It's mandatory to fail early. You need to know you're in trouble right away. That's essential when taking over an existing project or starting something new. You have to find out how you're doing within weeks. Not quarters, not months. The longer you wait, the more inertia the failure will have."

We're getting better at this, and I've sort of made it my mantra for this release cycle. Get things in to experimental as fast as possible, and then when I've fixed the majority of the bugs that show up there, put it in unstable as fast as possible. It worked out well for all the releases I've done so far and I'm going to keep doing it. Michel is really pushing me to keep CVS (or git as of Real Soon Now) snapshots from upstream in experimental, and I really like this idea and plan to follow through with it for this reason. This also echoes some of aj's ideas about speeding up development pace. Hopefully he'll implement them whether or not he becomes DPL, because I think they're going to be important for Debian as a whole.

"Dates are sacred."

We learned this during the sarge release cycle.

"The net result is that I've tried to find the happy medium where I generate weekly management reports on projects. A management report is something that is used to actually make a decision. Everything else is garbage. I've learned that when I haven't had management reports for a project, failure has resulted."

This is an interesting idea. It sort of echoes how I try and provide status updates on my blog, as well as the "Bits from" emails, but perhaps something more like this would be useful. I may try and play with this idea in the near future.

There's a lot more in there, but this entry already got way too long. Hopefully there's some food for thought in there for everyone who's interested in how Debian is run. The Debian development model has carried us very far, but I can't shake the feeling that we need to make some critical changes for it to continue. This will require a certain degree of boldness, but in order to fix the problems with the project I think we just need to clench our teeth and go for it. With that, I'll leave you with one last line from the above: "And if you decide to make changes, have the courage to go 100% with your gut. I've failed more than once when I watered down my convictions in order to appease dissenters. The only thing worse than evangelizing change and failing is looking back and realized you might have succeeded if you'd held firm on your convictions."

I have not been very much involved in this year DPL campaigning, but I’m part of two DPL teams, thus I feel the need to give my point of view on the subject. I’m not really satisfied by how the current DPL team worked out, and being on the DPL candidate team of both Jeroen and Andreas gave me the opportunity to gather information on what really happened. Also I’ve met Bdale yesterday and he gave me his opinion as well (and I really enjoyed that dinner. Thanks bdale!). Just for the record, I’ll try to sum up what really happened: Branden had agreed to be a participant of the DPL team concept, but wasn’t a major proponent of the idea. This, combined with his personal problems, explains why he didn’t make use of the full potential of a DPL team. Does it invalidate the DPL team concept? No, I don’t think so because the concept will evolve this year. Let’s see how it can change. Both DPL teams would this year receive all the mails sent to leader@debian.org. This means that the members are involved from the beginning and not only on request of the leader, which means that they can pro-actively take over if they see that the DPL doesn’t manage to follow up up to its expectations (which hopefully won’t be needed this year). Furthermore I expect that the team would be informed of what the DPL does, so that the team can give its opinion on everything done, and prevent big errors (nobody is perfect, errors do happen). But the most important thing is that the team should not stand behind the DPL, but next to him taking initiatives, and I expect the DPL to work with the team members for the best of Debian. As such I expect the DPL to accept most of the proposals of his team if there’s a consensus on it, even if he doesn’t personnaly think that’s it’s a priority for his DPL mandate. If I am part of an elected DPL team, I will work on that basis. I do have many ideas to try, and will make proposals. I ran once for the DPL election, and if you check my platform, you can see that I always had ideas for Debian and you can see that I worked on several of them which are nowadays very common (such as the PTS, alioth, collaborative maintenance). I won’t miss an opportunity to get the project moving forward.

Branden, hear, hear. Shave it, kill it, get rid of it. Alternatively, grow a goatee.

Since Joey Hess posted a short conversation we had on IRC today about the role of the DPL, I thought it's a good time to express some of my thoughts. Basically, I think that most people have a bad understanding of which tasks are really involved in being DPL (e.g. much more purely administrative crap that nobody else wants to do) and that they're quite naive about what the DPL can achieve, at least in the current climate. Let's just look at the current discussions on the -vote list. It's this time of the year when everyone pretends that its Christmas, expresses their feelings of what's wrong with Debian and where Santa Claus^W^Wthe candidates reassure them that everything will be fine. "Will you fix NM? Fix or replace ftp-master? etc." "Oh, sure I will, all of that (and more)." Honestly, would you elect someone if they told you they won't or can't? The strange thing is that the same questions get asked every year, and yet people don't get the hint and look for other solutions. I'm not overly happy with any of the candidates this year, and I was seriously considering running again, not next year but possibly later. However, this Christmas wankfest reminded me again why that may not be such a good idea after all. I remember how much time I spent answering questions on -vote myself, and while I'm all for transparency, many of the questions were just a waste of time. This year, the questions were relatively sane in the beginning but now it's just a waste of time most questions are posed in a way that it's clear what kind of answer people want to hear. I spent hours and hours answering questions, but at some point I thought "cannot we just stop talking for hours about what I'd do if elected and actually start doing all that stuff?". That would have been so much more productive. Instead of asking the DPL what they'll do to solve All The Problems In Debian, why don't you ask yourself what you can do to improve the situation? There's a bottleneck with the DAM, you say. Right, the chances that you'll be added as DAM are relatively small. But have you ever considered helping the DAM and to make their life easier? How about signing up as an Application Manager and producing such good reports that it'll be a piece of cake for the DAM to approve people based on your reports? Right, it won't fix the bottleneck, but it will make the situation so much better. Instead of bitching about the security team, why don't you prepare a package, write the text for the DSA and get everything ready in a way that a DSA member can simply take your work, recompile the package and issue the advisory? Now I'm sure some people will say that they've tried that and failed. Yes, not every upload for DSA will be accepted as it is, but how hard have you tried? And people always complain about the cabal and how hard it is to join teams. And while I agree that this is partly true, there are so many counter examples too. Look at me as an example. In 2.5 years, I became the most productive Application Manager, joined (and took over) the NM Front Desk, became a "senior" Quality Assurance member, and got elected as project leader. Am I special? No, in no way I just put in a lot of effort. Look at Jeroen van Wolffelaar, who joined at the end of 2004, and who is involved in QA (especially MIA) and lintian, is the co-author of the new packages.d.o code and an ftp assistant. Andi Barth (who got an account in January 2004) has done important QA work (bts2ldap), is a maintainer of the developers reference and a release manager. So it's not possible to join a team, you say? Maybe you're just not trying hard enough (and the right way!). (Hint: "make me a DAM/ftp-master/whatever" doesn't work as well as "how can I make your job easier?"). What I'm trying to say is that people should stop believing that the DPL will fix everything and that they should actually help out themselves. If we all work together and put effort into the areas that need work we might actually achieve something. People have been asking for a strong leader and this urge got stronger over the last few years. But, face it, we currently don't have a culture which accepts a strong leader. Joey Hess mentioned that he wants to see a DPL who pushes technical changes. I did that too, to some degree (mostly in private since that works much better than on a mailing list where a big flamewar is guaranteed). For example, I kindly asked Joey to lower the priority of the non-free question so it would not get asked in a default installation. And he did because Joey is a reasonable guy. (He also told me that me making this request made it easier for him to justify.) However, unfortunately, not everyone is like Joey. And what are you going to do if a maintainer refuses to listen, as many do? I mean, seriously, what can you do? Some are increasingly talking about the good old times of Bruce Perens who would tell people what to do and make decisions. The urge for a strong leader increased over the last years. I think that's partly a reason why Branden got elected last year people expected him to completely shake things up. I haven't talked to him and I wasn't part of the leadership team, so I don't really know what happened, but from what (little) I've heard, it seems that he tried, quickly realized just how rigid some of the structures are and gave up. You have to see things in a historical perspective (and I can only recommend that people who have access to the debian-private archives take the time to read through them). There's a reason we have had "weak" leaders since Bruce. While now a large number of people think that Bruce was the best thing since sliced bread, lots of people were really pissed off back then with him commanding people around. And what was the result? A constitution that would ensure that no leader would ever have such power again. And that's what we're currently stuck with. I think that one of the biggest problems Debian is currently facing is the inability to make decisions. There are so many endless, completely futile (and repetitive) discussions going on. We need someone who comes in, tells people to shut up and makes a decision on behalf of the project. A decision people will follow, even if they personally disagree with it. But seriously, do you think our culture would currently accept such a leader? I can tell you from experience that even people who have been asking for a "strong" leader won't actually follow a leader who tells them to take a certain course of action. We really need to fix this problem, and the problem is in our culture. And since our culture is defined by who we are, you should start with yourself first. Start by asking yourself a few questions. Do you think before posting something to our lists, and ask yourself twice whether it really adds value to the discussion? If there's an area that is problematic, will you try to help out? If asked to do something you're not particularly interested in but which is good for the project will you do it? And most importantly, will you contribute to make our culture something that is fun? The project leader is important, but don't wait for them to fix all of our problems. If there's a problem, try to figure out a way how you can solve it!

Bubulle had a wonderful idea. The Debian twins have been taken pics of in several Debconfs already. Some links for your viewing pleasure:

Debconf 2 - Toronto
[1] [2] [3] [1]

Debconf 3 - Oslo
[1]

Debconf 4 - Porto Alegre
My twin was not there :(

Debconf 5 - Helsinki
[1] [2]

Note to self: don't forget to shoot a picture of the Debian twins at Debconf6. Note (bis) to self: buy 300 fake mustaches, distribute them before the group photo, except to Branden. Shoot picture here as well.

It is kind of cute when you wake up, check your IRC backlog, and spurt out coffee all over your keyboard.
[micah] wow, who said branden looks like amaya?
[liw] micah, stockholm?
[micah] he's right
[micah] I thought that when i saw him in boston, with no moustache
[micah] but I didn't want him to hurt me
[dilinger] amaya should get a mustache, so we can tell them apart
/me LOLs

P.S: I have never liked Branden's moustache, so I am not very happy about getting one myself.

I’m back in Manila, again, to attend class. But this time around I’ll be staying longer here, maybe up until Thursday next week, since my dad will be coming here on Sunday so we can finally pack the last stuff we have back in our apartment at Makati. That means, among other things, I can actually attend the PLUG induction tomorrow. That also means, however, that I won’t be able to continue my work on my adopted packages or on MOTUToMerge in the coming week . Then again, I think I can fill in the blank hours by working on translations for Rosetta or do (ocular) inspections of packages up for REVU. Well, to keep focused here’s my TODO when I get back:

• Grok Overfiend’s WTFM, among other sources, and start to write manpages for robotour, dbacl, and gyach-improved
• Bring the autotools,dchroots,pbuilders stuff up to date
• Contact the ICL folks re: Edubuntu migration

 * Overfiend ROARS WITH RAGE
 <Overfiend> MISERABLE FILTH
 <Overfiend> I HAVE FOUND THE CAUSE OF 157891 AND LO I SHALL RAIN FIERY DEATH
             UPON THOSE RESPONSIBLE
 <Overfiend> nothing short of wrath and spite is enough to salve my pain
 <Overfiend> match(fp)   /* group substring between two KDELIM's; then do
             pattern match */
 <Overfiend>       switch (ctab[c])  
 <Overfiend>          case LETTER: case Letter:
 <Overfiend> ASS FUCKERS
 <Overfiend> no, it doesn't think "XFree86" is a "proper keyword" because it
             DARES TO HAVE DIGITS IN IT
 <Overfiend> ASS FUCKERS
 <Overfiend> DEATH DEATH DEATH
 <Overfiend> DEATH AND ETERNAL HELLFIRE UPON WHOEVER MADE THIS ASININE
             ASSUMPTION
 <Overfiend> Report problems and direct all questions to:
 <Overfiend>     rcs-bugs@cs.purdue.edu
 <Overfiend> NO, I'D RATHER DRIVE UP TO WEST LAFAYETTE AND NAIL MY PATCH INTO
             THE SKULL OF WHOEVER IS ON THE OTHER END OF THAT ADDRESS
 

(AOL!) [ 7 ] Choice 1: Jonathan Walther
[ 1 ] Choice 2: Matthew Garrett
[ 1 ] Choice 3: Branden Robinson
[ 5 ] Choice 4: Anthony Towns
[ 3 ] Choice 5: Angus Lees
[ 2 ] Choice 6: Andreas Schuldei
[ 6 ] Choice 7: None Of The Above I haven’t been doing too much Debian work lately, but I think I’ll be uploading discover1-data and abiword soon. I will have to find a big chunk of time if I hope to do any kernel or d-i work.

Holger Levsen wrote me with news from "the lost video" from debconf-es II. It has a special meaning for me, as my old boss and dear friend, Salvador Garcia, talks about the reasons we must continue looking for new software options continuosly. Holger gets the VHS tape and i didn't remember about it. Thanks, Holger.

Finally my ipw2200 runs with the correct firmware version in 2.6.14. Uff.

I have spent this two last nights reviewing some packages from two future NM, Ivan Forcada and Javier Ballesteros. They are swscanner, ksalup and mgm. Sponsoring packages is really hard. If they were my own packages i have not to explain what i see inadecuate, but i think is worth enough because they have much ilusion and desire to contribute something to the project. Amaya talk in debconf-es II about "El sponsor, ese animal esquivo" was really funny. I am thinking about creating an Amaya's Fun Club, as she made with Branden ;-)

Be careful with alcohol in the last night of the year. We call it in Spain "Noche Vieja".

Fun for all.

h01ger thought that maybe I should clarify a few points in my blog. Well sure, I can do that. First of all, I think Joey does great security work. I am not attacking him for this. Second, I think Joey does a great job with Debian in general. However, I think he’s seriously harming Debian by not opening up and organizing the security infrastructure, and this is where my problem lies. I hope I’m getting this point across. There have been a number of attempts to revise the infrastructure and organization; a meeting in Oldenburg, where the testing-security crew attempted to get Joey to use their work; proposal(s?) by the DPL; AJ is now working on security queue stuff. I really do hope that Joey decides to work w/ AJ (or any of the other people who’ve suggested different ways to handle Debian security), for the sake of Debian. Joey keeps looking for additional manpower, and gets frustrated when people don’t contribute. Well, as someone who has attempted to contribute, and has seen others attempt to contribute, we get frustrated when our contributions are ignored (in the case of the kernel security update, the i386 and source packages apparently sat around for 4 months). Maybe if all this happened in the open, instead of amongst private emails (that often times go unanswered because Joey is busy), people might not get discouraged, and will continue contributing. I personally don’t think anything has been solved, and unless Joey is actively working w/ Branden or AJ in private, I don’t see any progress towards solving a problem that will require openness, organization, and trust. Manpower can follow after that.